1. Field of the Invention
The present invention pertains to wireless telecommunications, and particularly to method and apparatus for reconfiguration of radio link control (RLC) parameters during a connection.
2. Related Art and Other Considerations
In a typical cellular radio system, wireless user equipment units (UEs) communicate via a radio access network (RAN) to one or more core networks. The user equipment units (UEs) can be mobile stations such as mobile telephones (“cellular” telephones) and laptops with mobile termination, and thus can be, for example, portable, pocket, hand-held, computer-included, or car-mounted mobile devices which communicate voice and/or data with radio access network. Alternatively, the wireless user equipment units can be fixed wireless devices, e.g., fixed cellular devices/terminals which are part of a wireless local loop or the like.
The radio access network (RAN) covers a geographical area which is divided into cell areas, with each cell area being served by a base station. A cell is a geographical area where radio coverage is provided by the radio base station equipment at a base station site. Each cell is identified by a unique identity, which is broadcast in the cell. The base stations communicate over the air interface (e.g., radio frequencies) with the user equipment units (UE) within range of the base stations. In the radio access network, several base stations are typically connected (e.g., by landlines or microwave) to a radio network controller (RNC). The radio network controller, also sometimes termed a base station controller (BSC), supervises and coordinates various activities of the plural base stations connected thereto. The radio network controllers are typically connected to one or more core networks. The core network has various service domains, with an RNC having an interface to these domains.
One example of a radio access network is the Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN). The UMTS is a third generation system which in some respects builds upon the radio access technology known as Global System for Mobile communications (GSM) developed in Europe. UTRAN is essentially a radio access network providing wideband code division multiple access (WCDMA) to user equipment units (UEs). The Third Generation Partnership Project (3GPP) has undertaken to evolve further the UTRAN and GSM-based radio access network technologies.
The Universal Mobile Telecommunications (UMTS) Terrestrial Radio Access Network (UTRAN) accommodates both circuit switched and packet switched connections. There are several interfaces of interest in the UTRAN. The interface between the radio network controllers (RNCs) and the core network(s) is termed the “Iu” interface. The interface between a radio network controller (RNC) and its base stations (BSs) is termed the “Iub” interface. The interface between the user equipment unit (UE) and the base stations is known as the “air interface” or the “radio interface” or “Uu interface”. An interface between radio network controllers (e.g., between a Serving RNC [SRNC] and a Drift RNC [DRNC]) is termed the “Iur” interface.
The radio network controller (RNC) controls the UTRAN. In fulfilling its control role, the RNC manages resources of the UTRAN. Such resources managed by the RNC include (among others) the downlink (DL) power transmitted by the base stations; the uplink (UL) interference perceived by the base stations; and the hardware situated at the base stations.
A UMTS Terrestrial Radio Access Network (UTRAN) responds to radio access service requests by allocating resources needed to support a communication with a user equipment unit (UE). A procedure for establishing a radio access bearer is described in Technical Specification 3GPP TS 25.931 v 5.1.0, which is incorporated herein by reference. A radio access bearer (RAB) is a logical connection with the user equipment unit (UE) through the UTRAN and over the radio air interface and corresponds to a single data stream. For example, one radio access bearer may support a speech connection, another bearer may support a video connection, and a third bearer may support a data packet connection. Each radio access bearer is associated with quality of service (QoS) parameters describing how the UTRAN should handle the data stream. Although the term “radio access bearer” is sometimes used for purposes of the following description, the invention applies to any type of “connection,” and is not limited to logical connections like RABs, a particular type of physical connection, etc.
To initiate a radio access bearer service, a request is transmitted to the UTRAN for communication with a user equipment unit (UE). One or more parameters accompany the radio access bearer service request. When establishing each bearer, the UTRAN “maps” or allocates the radio access bearer to physical transport and radio channel resources through the UTRAN and over the radio air interface, respectively. The mapping is based on one or more parameters associated with the radio access bearer service request.
In the Universal Mobile Telecommunications System (UMTS), a Radio Link Control (RLC) layer with its RLC protocol is interposed between a higher layer (such as an Internet Protocol (IP) Layer) and a Medium Access Control (MAC) layer. Radio link control (RLC) is a protocol layer that has various uses. The radio link control (RLC) has several modes of operation, including the transparent mode, the unacknowledged mode, and the acknowledged mode (AM). The RLC PDUs used in AM mode are called AMD PDUs (for RLC PDUs carrying user data. The mode of operation is selected according to the requirements of the higher layer. The radio link control (RLC) is used both for data flows and also for signaling flows.
FIG. 1 shows a Radio Link Control (RLC) layer 10 which transmits RLC PDUs (Protocol Data Units) to, and receives RLC PDUs from, the Medium Access Control (MAC) layer 11. In the illustrative example of FIG. 1, the Medium Access Control (MAC) layer 11 functions as the “lower layer” relative to the RLC layer; the “higher layer” 12 can be a layer such as TCP/IP layer (e.g., IP layer). The Medium Access Control (MAC) layer 11 is responsible, e.g., for mapping between logical channels and transport channels, priority handling, and scheduling of data flows on transport channels.
A radio access bearer (RAB) is established for each service. For each radio access bearer at least one RLC entity is established in both the user equipment unit and in the UTRAN. In the case of AM RLC there is one entity established, in the case of UM and TM there may be one downlink and one uplink RLC entity (or only a single RLC entity in one direction.
FIG. 1, shows, for an AM mode, an RLC entity 10-UE is provided in a user equipment unit (UE) and a RLC entity 10-RAN is provided in the UTRAN. With respect to the lower layer (e.g., Medium Access Control (MAC) layer 11), each RLC entity has a transmitting side and a receiving side. With its RLC PDUs, the RLC protocol of the Radio Link Control (RLC) layer supports the in-sequence delivery of higher level Service Data Units (SDUs) (which, in the illustration of FIG. 1, are TCP/IP IP packets). The Radio Link Control (RLC) layer is described in more detail in 3GPP TS 25.322 V6.0.0 (2003-12), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; RLC Protocol Specification (Release 6), which is incorporated herein by reference.
Some limited code-type error recovery capability (e.g., convolutional coding) is provided over the air interface (i.e., radio interface). Over the air interface, such error, recovery is performed locally with a local retransmission protocol, wherein all data in a transmission buffer is cached until it has been successfully delivered. In this regard, for example, the Radio Link Control (RLC) protocol of the Radio Link Control (RLC) layer has its local retransmission protocol—the Automatic Repeat Request (ARQ) protocol.
Consider the scenario of a user equipment unit (UE) with UE reference class 384 kbps. According to Technical Specification 3GPP TS 25.306 v 5.70, which is incorporated herein by reference, typical RLC capabilities for this UE class feature 50 Kbyte UE memory and a maximum of six AM (acknowledge mode) RLC entities. Thus, this user equipment unit (UE) can potentially use three parallel packet switched (PS) RABs. But, for the sake of simplicity, in this present scenario assume that this user equipment unit (UE) operates with two simultaneous PS RABs, e.g. two parallel interactive RABs or one interactive and one streaming RAB.
For an RLC entity which operates in AM mode, a mechanism which functions like a sliding window is used to control the flow of RLC packet data units (PDUs). When the first PS RAB is setup for the user equipment unit (UE) of this scenario, the UTRAN can not yet know if a second (or even a third ) PS RAB will be setup in the future. So if the RLC window size of the first PS RAB can not be reduced when a subsequent RAB is setup, then the UTRAN must take into account the memory usage of other RABs that may potentially be setup in the future. For example, to allow, e.g., two parallel PS RABs, UTRAN can only allocate half of its available UE memory for the first PS RAB.
In this scenario, if only the first PS RAB were to be setup, UTRAN could possibly allocate the whole remaining memory for the first PS RAB, e.g. a window size 512 in downlink and 256 in uplink, resulting in a total memory usage of 42 kbyte. But without the ability to reconfigure RLC window size, such ample memory allocation for the first PS RAB cannot occur. This is because the potential memory usage of a second PS RAB needs to be considered at the outset when the first PS RAB is setup (regardless of whether the second PS RAB will ever actually be setup). As a result, the RLC memory for the first RS RAB (and thus the RLC window size for the first PS RAB) can only be configured to, e.g., 256 in downlink and 128 in uplink. Naturally, this results in reduced performance, particularly before the second PS RAB is setup (which may never occur).
Especially for higher data rates, e.g. 384 kbps, the RLC window size has a significant impact on the performance in terms of delay/throughput. Since two parallel PS RABs may only be used in a fraction of the PS connections, this implies that a large amount of the UE memory is unused for most UEs and the throughput for PS connections unnecessarily low. The performance reduction is even more acute when cases of three parallel PS RABs are considered: the UTRAN can only allocate one third of the available UE memory when setting up the first PS RAB.
On the other hand, if the RLC window size could effectively be reduced at reconfiguration, the UTRAN could possibly allocate the whole memory for the first PS RAB. Then, if a second PS RAB is later setup, the window sizes could be reconfigured to suit the number of simultaneous RABs.
As it turns out, RRC signalling standards currently nominally support reconfiguration of RLC parameters during a connection, e.g. with a RADIO BEARER RECONFIGURATION message. The reconfiguration of RLC window size is ostensibly supported according to Technical Specification 3GPP TS 25.331 v 3.17.0 section 8.2.2.3 and 8.6.4.9, which is incorporated herein by reference.
However, the actions related to such a reconfiguration, particularly a reduction of the RLC window size, are not explicitly specified, e.g., neither in the above-mentioned Technical Specification 3GPP TS 25.322 nor in Technical Specification 3GPP TS 25.331. v 3.17.0, both which are incorporated herein by reference. Moreover, when the window size is decreased the UE actions are not unambiguous and potentially very problematic.
What is needed, therefore, and an object of the present invention, is an effective technique for implementing a decrease of the RLC window size.